There are several systems currently in use for creating electronic program guides for television programming. Cable television lineups often include one channel that provides a continuously scrolling grid of current and upcoming program information for the various channels carried by the cable system. These systems are relatively simple to implement, but they lack convenience for users: there is no way for the user to go directly to a given channel and time (other than waiting for that channel/time to scroll into view).
Another way of constructing an electronic program guide is to include data about the content within the content stream. This in-band data is used by most broadcast, cable and satellite digital television systems. The receiving device reads the data out of the content stream and then uses the data to populate an electronic program guide. Some systems, mostly cable and satellite, include a single data feed that encompasses all channels carried by the system. Other systems embed data into each content stream; this is the system used by broadcast television (PSIP). In either of these systems, the content distributor is responsible for supplying the data. It is impossible, or at least inconvenient, for users to specify another source for the data.
With in-band data, the content distributor is responsible for deciding how much data to include in the stream and how quickly to deliver it in the stream. The content distributor could decide to provide a large quantity of data in a short time, but this requires substantial bandwidth. The alternatives are to provide a small amount of data, or to spread the data over a long time, but either alternative has drawbacks. The amount of data can be minimized by limiting the time coverage (e.g., send one day's data instead of fourteen days' data) or by limiting the size of the individual items (e.g., limit program descriptions to 255 characters); in either case, the user gets less information about the programming. Another way to minimize the size of the data is to compress it. This can be very effective in limiting the size of the data, but can cause extra expense on the client side to decompress the data. If the data is delivered over a long period of time, the bandwidth is minimized, but it may take a long time for users to get a full set of data. In summary, in-band data can be effective, but it is often not very flexible.
One alternative to in-band data is to get the data describing the content from a source other than the actual content stream, usually a remote server. This requires that the client device have a way to communicate with the remote server, but has the advantage of being very flexible: every client device can potentially get a data set that is optimized for its configuration and capabilities. In the usual implementation of this method, the user is required to initialize the client device, usually supplying a zip code and picking a service provider (cable system, over the air, etc.) the first time the client device is turned on. The client device then contacts the remote server to get a set of data for the relevant service provider.
There are several problems with this implementation. First, it requires user input, which is generally problematic. Second, it assumes that the remote server can accurately determine what channels the client device can receive. In the case of over-the-air television transmissions, the set of channels received can vary over the span of a few feet, let alone the area of a zip code. In the case of cable systems, the set of channels that a given customer can receive is dependent on that customer's specific subscription package. The proliferation of subscription options means that, in general, no one but the cable operator is likely to know exactly what channels are included in today's package.
Many systems deal with the uncertainty of lineup information by allowing the customer to add or delete channels, producing a custom lineup for each customer. In theory, this is fine. In practice, however, lineups change, invalidating the customers' changes. There is also the problem with requiring customer input.